Field devices are commonly employed in automation technology (process automation/manufacturing automation) and serve for registering and/or influencing process variables. Examples of such field devices are fill level measuring devices, mass flow measuring devices, pressure- and temperature-measuring devices, pH- and redox-potential-measuring devices, conductivity measuring devices, etc. for process automation technology, which, as sensors, register the corresponding process variables, fill level, flow, e.g. flow rate, pressure, temperature, pH-value and conductivity value, respectively.
Serving for influencing process variables are actuators, e.g. valves, which control flow of a liquid in a section of pipeline, or pumps, which change fill level in a container.
A large number of such field devices are manufactured and sold by the firm ENDRESS+HAUSER®.
Frequently, field devices are connected with superordinated units via communication systems (PROFIBUS®, FOUNDATION-FIELDBUS®, HART®, etc.). Such superordinated units serve for process control, process visualization, device-management (configuration and servicing) and for plant management (asset management), using corresponding application programs.
The integration of field devices into such applications occurs via device descriptions. Device descriptions are provided by device manufacturers, in order that superordinated units can recognize and interpret the meaning of data supplied by the field devices.
Various device descriptions are known for the different fieldbus systems (HART-device-descriptions, Fieldbus Foundation device descriptions, Profibus device descriptions).
On the basis of cooperation of Fieldbus Foundation (FF), HART Communication Foundation (HCF) and Profibus Nutzerorganisation (PNO), an electronic device description (Electronic Device Description EDD) was created, which is defined in the standard IEC 61804-2.
With a large number of EDD-based fieldbus systems installed worldwide, EDD is a very widely used description language for device descriptions in automation technology.
For servicing field devices, corresponding servicing programs (operating tools) are necessary, which, in superordinated units, run either on their own (Endress+Hauser FieldCare, Pactware, AMS Fisher-Rosemount, PDM Siemens) or else are integrated into control system applications (Siemens PCS7, ABB Symphony, Emerson Delta V).
For a comprehensive servicing of field devices, newly, special device descriptions, so-called DTMs (Device Type Manager), are available, which correspond to the FDT (Field Device Tool) specifications. The FDT-specifications, serving as an industry standard, were developed by the PNO (Profibus Nutzer Organisation (Profibus User Organization)) in cooperation with ZVEI (Zentralverband Elektrotechnik-und Elektroindustrie (The German Electrical and Electronics Industry, a registered association)). The current FDT-Specification 1.2.1, including the Addendum for “Foundation Fieldbus” Communication, is available from ZVEI, PNO or the FDT-Group.
Many field device manufacturers already deliver corresponding DTMs for their field devices. The DTMs encapsulate all variables and functions of the pertinent field device and offer, most often, a graphical user interface for servicing the devices.
As run-time environment, the DTMs require a frame application (FDT-frame). The frame application and the corresponding DTMs permit, thus, a very comfortable access to field devices (e.g. to device parameters, measured values, diagnostic information, status information, etc.), as well as for invoking special functions, which individual DTMs make available.
The DTMs can be referred to as device objects, which, together with the frame application, represent an object-oriented configuration system for field devices of automation technology.
In order to keep the administration of device objects as simple as possible in superordinated units, the field-device manufacturers do not provide a separate DTM for each field device, but, instead, a main, or principal, object, which includes a plurality of device objects for individual field device types of the particular manufacturer.
If a malfunction occurs during the servicing of a field device, then the corresponding device object must be updated. An updating is also necessary, when the device receives new functionalities, which could not be accessed via the device object present until now.
Problematic is the integration of updated device objects into object-oriented configuration systems when main objects are being used. One possibility is to produce an updated device object and also a correspondingly updated main object. This means, however, a considerable test effort, since not only the updated device object must be tested, but, also, all other device objects of the relevant main object.
Another possibility is to generate, for the updated device object, an updated main object and to remove the not-updated device object from the original main object. There arises, along with the original device object, a completely independent device object. This, however, changes the modular structure of the configuration system and the user must institute considerable adaptations in its system.
Both alternatives mean for the operation of an object-based configuration system, in the case of updating of device objects, a considerable effort, either on the part of the device manufacturer or on the part of the user.